Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0799/413

Internet Message Format | 1994-08-27 | 6KB

Date: Sun, 12 Jun 94 00:03 BST-1
From: Ofir Gal <[e-mail]>
Subject: Ofir's digest 11.06
To: [e-mail]
Message-Id: <[e-mail]>
Precedence: bulk


In message <[e-mail]>, [e-mail] said:
>
>Why would it be so hard to establish some keys to be slightly different in
>other country/languages? I'm not saying we should do this, but that there
>very well may be an interest in doing so. A program could automatically
>switch or allow for different defaults at installation.

I think it will result in chaos similar to the one we have ATM. While it
may be OK for commercial programs with good distribution, it will not
help shareware.

>If we are heading towards a global configuration file, then why NOT have
>each country logical to their own language? Just load in the US, UK,
>GERMAN, FRENCH, SPAIN, MEXICO, CHILE, ITALY, ISRAEL, or other appropriate
>file. I would think this setup would be PERFECT for that purpose.

Indeed, this is one of the reasons such a config is a good idea.

>> I am ready and so are others.
>
>That doesn't mean everyone will. We've been through this before. Atari
>convinced us to implement the "official" Atari clipboard standard into
>STalker and STeno. Six months later they "changed" the standard, after we
>had released both applications. STalker has been upgraded since then to
>support "both" official standards (some programs use the older standard
>while others use the newer one). STeno hasn't been upgraded yet (we can
>only do so much at once), but we finally have someone working on this.

I am not aware of any changes to the clip standard. My GEM docs from 89
are the same as the 93 COmpendium. We had this discussion before on
Usenet. Non-standard implementation is one of the reason I stopped using
STalker (although I paid full price for it) and moved on to use CoNnect.

>However, when people ask what other programs support either clipboard
>standard, the answer is "not much".

That is not the case with German software. Most programs on my system
fully support the GEM clip and a it's a very useful feature.

>From a developer standpoint, this is nothing less than a nightmare. The
>Atari market is SMALL. Having to go back and modify an application before
>you were ready to upgrade it (because some standard has changed) can be a
>financial nightware.

It depends on your code, it will take me about 1/2 an hour to make my
Voice Mail program compliant to the new standard. I also believe that if
the standard is established, users will come to expect programs to use it,
if you want your products to sell in Germany (and the UK market is also
moving in this direction) you will have to produce programs that follow
the guidelines (if you can decide which guidelines to follow :-).

>I know this sounds negative. I'm really not trying to be, just trying to
>point out some of the issues us "commercial" developers face.  This is
>part of the reason we've been heading toward giving the customer complete
>flexibility.

Many people on the list are commercial developers. They face the same
problems you do - me included. I believe that a standard interface can
only help our market.

>Reviews might point out the logic of this (though we don't really have
>many magazines left doing reviews these days). But a customer who's been
>hanging on to their STalker since day one may not want his keys to change
>without warning.

I can't speak for other users, but _I_ will be very happy if STalker was
changed to follow the standards.

>As a developer, I can see this heading towards seeing applications
>shipping with two sets of keyboard_control_files. One with the original
>set, and one with newer standard.

That's possible. If your original keyboard settings greatly differ from
the standard.

>> here is a much better solution. Allowing the user to define the keyboard
>> shortcuts for all apps in one go.
>
>It makes sense, as long as the decision is implemented with enough ease
>of use so that all levels of programmers can support it. Sure, we can do
>almost anything we want in code. But there are many GEM programmers who
>barelly understand how they got a window up, must less how to do
>overlays, etc. In other words, we want to keep any standard implemented
>at a low technical level to assist novice programmers. (Sorry if this
>paragraph is confusing, several thoughts at once in it).

I fully agree with you. We are currently debating the format of the
configuration file. Your comments will be useful.


In message <[e-mail]>, [e-mail] said:
>
>No; here is an example of what "Abandon" does.  Assume that I have a text
>file on a disk.  It contains the words "This is a text file.".  I load
>the text file into my editor, and change the sentence to something
>else.  I decide that I want the original back, so I press Control-H.
>The changes are thrown away and the document is reloaded.  It does
>no close the window, iconify it, or do anything to it except restore
>the document in it to its original form.

I see what you mean. HiSoft call this revert. I'm not sure if a keyboard
shortcut is required fro such an option. Comments?

In message <[e-mail]>, [e-mail] said:
>
>Ofir Gal:
>>CTRL D -                 Abandon Window (iconify or place in menu)
>I'd prefer CTRL-H.

Which should we use then? CTRL+D or CTRL+H? Are there any programs that
implement this feature? Maybe Wilfried can tell us why he wants CTRL+D
since it was his idea.

Bye,

Ofir                                    [e-mail]